ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್‌ನಲ್ಲಿ ಪ್ರಾವೀಣ್ಯತೆ: ಹಂಚಿಕೆಯ ವ್ಯಾಪ್ತಿ ಮತ್ತು ಅವಲಂಬನೆ ಹಂಚಿಕೆಯ ಶಕ್ತಿ

ವೆಬ್ ಅಭಿವೃದ್ಧಿಯ ವೇಗವಾಗಿ ಬದಲಾಗುತ್ತಿರುವ ಜಗತ್ತಿನಲ್ಲಿ, ವಿಸ್ತರಿಸಬಲ್ಲ ಮತ್ತು ನಿರ್ವಹಿಸಬಲ್ಲ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಅತ್ಯಾಧುನಿಕ ಆರ್ಕಿಟೆಕ್ಚರಲ್ ಮಾದರಿಗಳನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ. ಇವುಗಳಲ್ಲಿ, ಮೈಕ್ರೋಫ್ರಂಟೆಂಡ್‌ಗಳ ಪರಿಕಲ್ಪನೆಯು ಗಮನಾರ್ಹವಾದ ಮನ್ನಣೆ ಗಳಿಸಿದೆ, ಇದು ತಂಡಗಳಿಗೆ ಅಪ್ಲಿಕೇಶನ್‌ನ ಭಾಗಗಳನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಮತ್ತು ನಿಯೋಜಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಈ ಸ್ವತಂತ್ರ ಘಟಕಗಳ ನಡುವೆ ಸುಗಮ ಏಕೀಕರಣ ಮತ್ತು ದಕ್ಷ ಕೋಡ್ ಹಂಚಿಕೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವ ಹೃದಯಭಾಗದಲ್ಲಿ ವೆಬ್‌ಪ್ಯಾಕ್‌ನ ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ಪ್ಲಗಿನ್ ಇದೆ, ಮತ್ತು ಅದರ ಶಕ್ತಿಯ ಒಂದು ನಿರ್ಣಾಯಕ ಅಂಶವೆಂದರೆ ಹಂಚಿಕೆಯ ವ್ಯಾಪ್ತಿ (shared scope).

ಈ ಸಮಗ್ರ ಮಾರ್ಗದರ್ಶಿಯು ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್‌ನೊಳಗಿನ 'ಹಂಚಿಕೆಯ ವ್ಯಾಪ್ತಿ'ಯ ಯಾಂತ್ರಿಕತೆಯನ್ನು ಆಳವಾಗಿ ಪರಿಶೀಲಿಸುತ್ತದೆ. ಇದು ಏನೆಂದು, ಅವಲಂಬನೆ ಹಂಚಿಕೆಗೆ ಇದು ಏಕೆ ಅತ್ಯಗತ್ಯ, ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಪ್ರಾಯೋಗಿಕ ತಂತ್ರಗಳನ್ನು ನಾವು ಅನ್ವೇಷಿಸುತ್ತೇವೆ. ನಮ್ಮ ಗುರಿಯು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಈ ಪ್ರಬಲ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಉತ್ತಮ ಕಾರ್ಯಕ್ಷಮತೆ, ಕಡಿಮೆ ಬಂಡಲ್ ಗಾತ್ರಗಳು, ಮತ್ತು ವೈವಿಧ್ಯಮಯ ಜಾಗತಿಕ ಅಭಿವೃದ್ಧಿ ತಂಡಗಳಾದ್ಯಂತ ಸುಧಾರಿತ ಡೆವಲಪರ್ ಅನುಭವಕ್ಕಾಗಿ ಬಳಸಿಕೊಳ್ಳಲು ಜ್ಞಾನವನ್ನು ಒದಗಿಸುವುದಾಗಿದೆ.

ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ಎಂದರೇನು?

ಹಂಚಿಕೆಯ ವ್ಯಾಪ್ತಿಯ ಬಗ್ಗೆ ತಿಳಿದುಕೊಳ್ಳುವ ಮೊದಲು, ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್‌ನ ಮೂಲಭೂತ ಪರಿಕಲ್ಪನೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಬಹಳ ಮುಖ್ಯ. ವೆಬ್‌ಪ್ಯಾಕ್ 5 ರೊಂದಿಗೆ ಪರಿಚಯಿಸಲಾದ ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್, ಒಂದು ಬಿಲ್ಡ್-ಟೈಮ್ ಮತ್ತು ರನ್-ಟೈಮ್ ಪರಿಹಾರವಾಗಿದ್ದು, ಇದು ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಪ್ರತ್ಯೇಕವಾಗಿ ಕಂಪೈಲ್ ಮಾಡಲಾದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ನಡುವೆ ಕೋಡ್ (ಲೈಬ್ರರಿಗಳು, ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳು, ಅಥವಾ ಸಂಪೂರ್ಣ ಕಾಂಪೊನೆಂಟ್‌ಗಳು) ಅನ್ನು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಹಂಚಿಕೊಳ್ಳಲು ಅನುಮತಿಸುತ್ತದೆ. ಇದರರ್ಥ ನೀವು ಅನೇಕ ವಿಭಿನ್ನ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ('ರಿಮೋಟ್‌ಗಳು' ಅಥವಾ 'ಕನ್ಸ್ಯೂಮರ್‌ಗಳು' ಎಂದು ಕರೆಯಲ್ಪಡುವ) ಹೊಂದಬಹುದು, ಅದು 'ಕಂಟೇನರ್' ಅಥವಾ 'ಹೋಸ್ಟ್' ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ಕೋಡ್ ಅನ್ನು ಲೋಡ್ ಮಾಡಬಹುದು, ಮತ್ತು ಪ್ರತಿಯಾಗಿ ಕೂಡ.

ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್‌ನ ಪ್ರಾಥಮಿಕ ಪ್ರಯೋಜನಗಳೆಂದರೆ:

• ಕೋಡ್ ಹಂಚಿಕೆ: ಅನೇಕ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಾದ್ಯಂತ ಅನಗತ್ಯ ಕೋಡ್ ಅನ್ನು ತೆಗೆದುಹಾಕಿ, ಒಟ್ಟಾರೆ ಬಂಡಲ್ ಗಾತ್ರಗಳನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಲೋಡ್ ಸಮಯವನ್ನು ಸುಧಾರಿಸುತ್ತದೆ.
• ಸ್ವತಂತ್ರ ನಿಯೋಜನೆ: ತಂಡಗಳು ದೊಡ್ಡ ಅಪ್ಲಿಕೇಶನ್‌ನ ವಿವಿಧ ಭಾಗಗಳನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಬಹುದು ಮತ್ತು ನಿಯೋಜಿಸಬಹುದು, ಇದು ಚುರುಕುತನ ಮತ್ತು ವೇಗದ ಬಿಡುಗಡೆ ಚಕ್ರಗಳನ್ನು ಉತ್ತೇಜಿಸುತ್ತದೆ.
• ತಂತ್ರಜ್ಞಾನದ ಅಜ್ಞೇಯತಾವಾದ: ಪ್ರಾಥಮಿಕವಾಗಿ ವೆಬ್‌ಪ್ಯಾಕ್‌ನೊಂದಿಗೆ ಬಳಸಲಾಗಿದ್ದರೂ, ಇದು ವಿವಿಧ ಬಿಲ್ಡ್ ಪರಿಕರಗಳು ಅಥವಾ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳಾದ್ಯಂತ ಹಂಚಿಕೆಯನ್ನು ಸುಗಮಗೊಳಿಸುತ್ತದೆ, ನಮ್ಯತೆಯನ್ನು ಉತ್ತೇಜಿಸುತ್ತದೆ.
• ರನ್‌ಟೈಮ್ ಏಕೀಕರಣ: ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ರನ್‌ಟೈಮ್‌ನಲ್ಲಿ ಸಂಯೋಜಿಸಬಹುದು, ಇದು ಕ್ರಿಯಾತ್ಮಕ ನವೀಕರಣಗಳು ಮತ್ತು ಹೊಂದಿಕೊಳ್ಳುವ ಅಪ್ಲಿಕೇಶನ್ ರಚನೆಗಳಿಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.

ಸಮಸ್ಯೆ: ಮೈಕ್ರೋಫ್ರಂಟೆಂಡ್‌ಗಳಲ್ಲಿ ಅನಗತ್ಯ ಅವಲಂಬನೆಗಳು

ನೀವು ಅನೇಕ ಮೈಕ್ರೋಫ್ರಂಟೆಂಡ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ಸನ್ನಿವೇಶವನ್ನು ಪರಿಗಣಿಸಿ, ಅವೆಲ್ಲವೂ ರಿಯಾಕ್ಟ್‌ನಂತಹ ಜನಪ್ರಿಯ UI ಲೈಬ್ರರಿಯ ಒಂದೇ ಆವೃತ್ತಿಯ ಮೇಲೆ ಅಥವಾ ರೆಡಕ್ಸ್‌ನಂತಹ ಸ್ಟೇಟ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಲೈಬ್ರರಿಯ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿವೆ. ಹಂಚಿಕೆಯ ಯಾಂತ್ರಿಕತೆಯಿಲ್ಲದೆ, ಪ್ರತಿಯೊಂದು ಮೈಕ್ರೋಫ್ರಂಟೆಂಡ್ ಈ ಅವಲಂಬನೆಗಳ ತನ್ನದೇ ಆದ ಪ್ರತಿಯನ್ನು ಬಂಡಲ್ ಮಾಡುತ್ತದೆ. ಇದು ಈ ಕೆಳಗಿನ ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ:

• ದೊಡ್ಡದಾದ ಬಂಡಲ್ ಗಾತ್ರಗಳು: ಪ್ರತಿಯೊಂದು ಅಪ್ಲಿಕೇಶನ್ ಅನಗತ್ಯವಾಗಿ ಸಾಮಾನ್ಯ ಲೈಬ್ರರಿಗಳನ್ನು ನಕಲು ಮಾಡುತ್ತದೆ, ಇದು ಬಳಕೆದಾರರಿಗೆ ದೊಡ್ಡ ಡೌನ್‌ಲೋಡ್ ಗಾತ್ರಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
• ಹೆಚ್ಚಿದ ಮೆಮೊರಿ ಬಳಕೆ: ಬ್ರೌಸರ್‌ನಲ್ಲಿ ಒಂದೇ ಲೈಬ್ರರಿಯ ಅನೇಕ ಪ್ರತಿಗಳು ಲೋಡ್ ಆಗುವುದರಿಂದ ಹೆಚ್ಚು ಮೆಮೊರಿ ಬಳಕೆಯಾಗಬಹುದು.
• ಅಸಂಗತ ವರ್ತನೆ: ಅಪ್ಲಿಕೇಶನ್‌ಗಳಾದ್ಯಂತ ಹಂಚಿಕೆಯ ಲೈಬ್ರರಿಗಳ ವಿಭಿನ್ನ ಆವೃತ್ತಿಗಳು ಸೂಕ್ಷ್ಮ ದೋಷಗಳು ಮತ್ತು ಹೊಂದಾಣಿಕೆಯ ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು.
• ನೆಟ್‌ವರ್ಕ್ ಸಂಪನ್ಮೂಲಗಳ ವ್ಯರ್ಥ: ಬಳಕೆದಾರರು ವಿಭಿನ್ನ ಮೈಕ್ರೋಫ್ರಂಟೆಂಡ್‌ಗಳ ನಡುವೆ ಸಂಚರಿಸಿದರೆ ಒಂದೇ ಲೈಬ್ರರಿಯನ್ನು ಹಲವು ಬಾರಿ ಡೌನ್‌ಲೋಡ್ ಮಾಡಬೇಕಾಗಬಹುದು.

ಈ ಸವಾಲುಗಳಿಗೆ ಸುಂದರವಾದ ಪರಿಹಾರವನ್ನು ನೀಡಲು ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್‌ನ 'ಹಂಚಿಕೆಯ ವ್ಯಾಪ್ತಿ' ಇಲ್ಲಿ ಕಾರ್ಯರೂಪಕ್ಕೆ ಬರುತ್ತದೆ.

ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್‌ನ ಹಂಚಿಕೆಯ ವ್ಯಾಪ್ತಿಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು

ಹಂಚಿಕೆಯ ವ್ಯಾಪ್ತಿ (shared scope), ಸಾಮಾನ್ಯವಾಗಿ ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ಪ್ಲಗಿನ್‌ನಲ್ಲಿ shared ಆಯ್ಕೆಯ ಮೂಲಕ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗುತ್ತದೆ, ಇದು ಅನೇಕ ಸ್ವತಂತ್ರವಾಗಿ ನಿಯೋಜಿಸಲಾದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಅವಲಂಬನೆಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಅನುವು ಮಾಡಿಕೊಡುವ ಯಾಂತ್ರಿಕತೆಯಾಗಿದೆ. ಕಾನ್ಫಿಗರ್ ಮಾಡಿದಾಗ, ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ನಿರ್ದಿಷ್ಟ ಅವಲಂಬನೆಯ ಒಂದೇ ಒಂದು ಪ್ರತಿಯನ್ನು ಲೋಡ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಲಭ್ಯವಾಗುವಂತೆ ಮಾಡುತ್ತದೆ.

ಅದರ ಮೂಲದಲ್ಲಿ, ಹಂಚಿಕೆಯ ವ್ಯಾಪ್ತಿಯು ಹಂಚಿಕೆಯ ಮಾಡ್ಯೂಲ್‌ಗಳಿಗಾಗಿ ಜಾಗತಿಕ ನೋಂದಣಿ ಅಥವಾ ಕಂಟೇನರ್ ಅನ್ನು ರಚಿಸುವ ಮೂಲಕ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಒಂದು ಅಪ್ಲಿಕೇಶನ್ ಹಂಚಿಕೆಯ ಅವಲಂಬನೆಯನ್ನು ವಿನಂತಿಸಿದಾಗ, ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ಈ ನೋಂದಣಿಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಅವಲಂಬನೆಯು ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದರೆ (ಅಂದರೆ, ಮತ್ತೊಂದು ಅಪ್ಲಿಕೇಶನ್ ಅಥವಾ ಹೋಸ್ಟ್‌ನಿಂದ ಲೋಡ್ ಆಗಿದ್ದರೆ), ಅದು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪ್ರತಿಯನ್ನು ಬಳಸುತ್ತದೆ. ಇಲ್ಲದಿದ್ದರೆ, ಅದು ಅವಲಂಬನೆಯನ್ನು ಲೋಡ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಭವಿಷ್ಯದ ಬಳಕೆಗಾಗಿ ಹಂಚಿಕೆಯ ವ್ಯಾಪ್ತಿಯಲ್ಲಿ ನೋಂದಾಯಿಸುತ್ತದೆ.

ಕಾನ್ಫಿಗರೇಶನ್ ಸಾಮಾನ್ಯವಾಗಿ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

            // webpack.config.js

const { ModuleFederationPlugin } = require('webpack');

module.exports = {
  // ... other webpack configurations
  plugins: [
    new ModuleFederationPlugin({
      name: 'container',
      remotes: {
        'app1': 'app1@http://localhost:3001/remoteEntry.js',
        'app2': 'app2@http://localhost:3002/remoteEntry.js',
      },
      shared: {
        'react': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
      },
    }),
  ],
};

            

              
                Copy
              
            
          

ಹಂಚಿಕೆಯ ಅವಲಂಬನೆಗಳಿಗಾಗಿ ಪ್ರಮುಖ ಕಾನ್ಫಿಗರೇಶನ್ ಆಯ್ಕೆಗಳು:

• singleton: true: ಇದು ಬಹುಶಃ ಅತ್ಯಂತ ನಿರ್ಣಾಯಕ ಆಯ್ಕೆಯಾಗಿದೆ. ಇದನ್ನು true ಎಂದು ಹೊಂದಿಸಿದಾಗ, ಎಲ್ಲಾ ಬಳಸುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಾದ್ಯಂತ ಹಂಚಿಕೆಯ ಅವಲಂಬನೆಯ ಒಂದೇ ಒಂದು ಪ್ರತಿ ಮಾತ್ರ ಲೋಡ್ ಆಗುವುದನ್ನು ಇದು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಅನೇಕ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಒಂದೇ ಸಿಂಗಲ್‌ಟನ್ ಅವಲಂಬನೆಯನ್ನು ಲೋಡ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದರೆ, ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ಅವರಿಗೆ ಅದೇ ಪ್ರತಿಯನ್ನು ಒದಗಿಸುತ್ತದೆ.
• eager: true: ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಹಂಚಿಕೆಯ ಅವಲಂಬನೆಗಳನ್ನು ಸೋಮಾರಿತನದಿಂದ ಲೋಡ್ ಮಾಡಲಾಗುತ್ತದೆ, ಅಂದರೆ ಅವುಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಆಮದು ಮಾಡಿಕೊಂಡಾಗ ಅಥವಾ ಬಳಸಿದಾಗ ಮಾತ್ರ ಪಡೆಯಲಾಗುತ್ತದೆ. eager: true ಎಂದು ಹೊಂದಿಸುವುದರಿಂದ ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಾರಂಭವಾದ ತಕ್ಷಣ ಅವಲಂಬನೆಯನ್ನು ಲೋಡ್ ಮಾಡಲು ಒತ್ತಾಯಿಸುತ್ತದೆ, ತಕ್ಷಣವೇ ಬಳಸದಿದ್ದರೂ ಸಹ. ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳಂತಹ ನಿರ್ಣಾಯಕ ಲೈಬ್ರರಿಗಳಿಗೆ ಇದು ಪ್ರಯೋಜನಕಾರಿಯಾಗಬಹುದು, ಅವು ಪ್ರಾರಂಭದಿಂದಲೇ ಲಭ್ಯವಿವೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು.
• requiredVersion: '...': ಈ ಆಯ್ಕೆಯು ಹಂಚಿಕೆಯ ಅವಲಂಬನೆಯ ಅಗತ್ಯವಿರುವ ಆವೃತ್ತಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ. ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ವಿನಂತಿಸಿದ ಆವೃತ್ತಿಯನ್ನು ಹೊಂದಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಅನೇಕ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ವಿಭಿನ್ನ ಆವೃತ್ತಿಗಳು ಬೇಕಾದರೆ, ಇದನ್ನು ನಿರ್ವಹಿಸಲು ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ಯಾಂತ್ರಿಕತೆಗಳನ್ನು ಹೊಂದಿದೆ (ನಂತರ ಚರ್ಚಿಸಲಾಗಿದೆ).
• version: '...': ಹಂಚಿಕೆಯ ವ್ಯಾಪ್ತಿಗೆ ಪ್ರಕಟಿಸಲಾಗುವ ಅವಲಂಬನೆಯ ಆವೃತ್ತಿಯನ್ನು ನೀವು ಸ್ಪಷ್ಟವಾಗಿ ಹೊಂದಿಸಬಹುದು.
• import: false: ಈ ಸೆಟ್ಟಿಂಗ್ ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್‌ಗೆ ಹಂಚಿಕೆಯ ಅವಲಂಬನೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಬಂಡಲ್ ಮಾಡದಂತೆ ಹೇಳುತ್ತದೆ. ಬದಲಾಗಿ, ಅದನ್ನು ಬಾಹ್ಯವಾಗಿ ಒದಗಿಸಲಾಗುವುದು ಎಂದು ಅದು ನಿರೀಕ್ಷಿಸುತ್ತದೆ (ಹಂಚಿಕೆ ಮಾಡುವಾಗ ಇದು ಡೀಫಾಲ್ಟ್ ನಡವಳಿಕೆಯಾಗಿದೆ).
• packageDir: '...': ಹಂಚಿಕೆಯ ಅವಲಂಬನೆಯನ್ನು ಪರಿಹರಿಸಲು ಪ್ಯಾಕೇಜ್ ಡೈರೆಕ್ಟರಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ, ಇದು ಮೊನೊರೆಪೋಗಳಲ್ಲಿ ಉಪಯುಕ್ತವಾಗಿದೆ.

ಹಂಚಿಕೆಯ ವ್ಯಾಪ್ತಿಯು ಅವಲಂಬನೆ ಹಂಚಿಕೆಯನ್ನು ಹೇಗೆ ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ

ಪ್ರಾಯೋಗಿಕ ಉದಾಹರಣೆಯೊಂದಿಗೆ ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ವಿಭಜಿಸೋಣ. ನಮ್ಮಲ್ಲಿ ಮುಖ್ಯ 'ಕಂಟೇನರ್' ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಎರಡು 'ರಿಮೋಟ್' ಅಪ್ಲಿಕೇಶನ್‌ಗಳು, `app1` ಮತ್ತು `app2` ಇವೆ ಎಂದು ಭಾವಿಸೋಣ. ಈ ಮೂರು ಅಪ್ಲಿಕೇಶನ್‌ಗಳು `react` ಮತ್ತು `react-dom` ಆವೃತ್ತಿ 18 ರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿವೆ.

ಸನ್ನಿವೇಶ 1: ಕಂಟೇನರ್ ಅಪ್ಲಿಕೇಶನ್ ಅವಲಂಬನೆಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತದೆ

ಈ ಸಾಮಾನ್ಯ ಸೆಟಪ್‌ನಲ್ಲಿ, ಕಂಟೇನರ್ ಅಪ್ಲಿಕೇಶನ್ ಹಂಚಿಕೆಯ ಅವಲಂಬನೆಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ. ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್‌ನಿಂದ ರಚಿಸಲಾದ `remoteEntry.js` ಫೈಲ್, ಈ ಹಂಚಿಕೆಯ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ.

ಕಂಟೇನರ್‌ನ ವೆಬ್‌ಪ್ಯಾಕ್ ಕಾನ್ಫಿಗ್ (`container/webpack.config.js`):

            const { ModuleFederationPlugin } = require('webpack');

module.exports = {
  // ...
  plugins: [
    new ModuleFederationPlugin({
      name: 'container',
      filename: 'remoteEntry.js',
      exposes: {
        './App': './src/App',
      },
      shared: {
        'react': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
      },
    }),
  ],
};

            

              
                Copy
              
            
          

ಈಗ, `app1` ಮತ್ತು `app2` ಈ ಹಂಚಿಕೆಯ ಅವಲಂಬನೆಗಳನ್ನು ಬಳಸುತ್ತವೆ.

`app1` ನ ವೆಬ್‌ಪ್ಯಾಕ್ ಕಾನ್ಫಿಗ್ (`app1/webpack.config.js`):

            const { ModuleFederationPlugin } = require('webpack');

module.exports = {
  // ...
  plugins: [
    new ModuleFederationPlugin({
      name: 'app1',
      filename: 'remoteEntry.js',
      exposes: {
        './Feature1': './src/Feature1',
      },
      remotes: {
        'container': 'container@http://localhost:3000/remoteEntry.js',
      },
      shared: {
        'react': {
          singleton: true,
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true,
          requiredVersion: '^18.0.0',
        },
      },
    }),
  ],
};

            

              
                Copy
              
            
          

`app2` ನ ವೆಬ್‌ಪ್ಯಾಕ್ ಕಾನ್ಫಿಗ್ (`app2/webpack.config.js`):

`app2` ಗಾಗಿ ಕಾನ್ಫಿಗರೇಶನ್ `app1` ಗೆ ಹೋಲುತ್ತದೆ, `react` ಮತ್ತು `react-dom` ಅನ್ನು ಒಂದೇ ಆವೃತ್ತಿಯ ಅವಶ್ಯಕತೆಗಳೊಂದಿಗೆ ಹಂಚಿಕೊಳ್ಳಲಾಗಿದೆ ಎಂದು ಘೋಷಿಸುತ್ತದೆ.

ರನ್‌ಟೈಮ್‌ನಲ್ಲಿ ಇದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ:

1. ಕಂಟೇನರ್ ಅಪ್ಲಿಕೇಶನ್ ಮೊದಲು ಲೋಡ್ ಆಗುತ್ತದೆ, ಅದರ ಹಂಚಿಕೆಯ `react` ಮತ್ತು `react-dom` ಪ್ರತಿಗಳನ್ನು ಅದರ ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ವ್ಯಾಪ್ತಿಯಲ್ಲಿ ಲಭ್ಯವಾಗುವಂತೆ ಮಾಡುತ್ತದೆ.
2. `app1` ಲೋಡ್ ಆದಾಗ, ಅದು `react` ಮತ್ತು `react-dom` ಅನ್ನು ವಿನಂತಿಸುತ್ತದೆ. `app1` ನಲ್ಲಿರುವ ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ಇವುಗಳನ್ನು ಹಂಚಿಕೆಯಾಗಿ ಮತ್ತು `singleton: true` ಎಂದು ಗುರುತಿಸಲಾಗಿದೆ ಎಂದು ನೋಡುತ್ತದೆ. ಇದು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪ್ರತಿಗಳಿಗಾಗಿ ಜಾಗತಿಕ ವ್ಯಾಪ್ತಿಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಕಂಟೇನರ್ ಈಗಾಗಲೇ ಅವುಗಳನ್ನು ಲೋಡ್ ಮಾಡಿದ್ದರೆ, `app1` ಆ ಪ್ರತಿಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡುತ್ತದೆ.
3. ಅಂತೆಯೇ, `app2` ಲೋಡ್ ಆದಾಗ, ಅದು ಅದೇ `react` ಮತ್ತು `react-dom` ಪ್ರತಿಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡುತ್ತದೆ.

ಇದರಿಂದ ಬ್ರೌಸರ್‌ಗೆ `react` ಮತ್ತು `react-dom` ನ ಒಂದೇ ಒಂದು ಪ್ರತಿ ಲೋಡ್ ಆಗುತ್ತದೆ, ಒಟ್ಟು ಡೌನ್‌ಲೋಡ್ ಗಾತ್ರವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ಸನ್ನಿವೇಶ 2: ರಿಮೋಟ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ನಡುವೆ ಅವಲಂಬನೆಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುವುದು

ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ರಿಮೋಟ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ತಮ್ಮ ನಡುವೆ ಅವಲಂಬನೆಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಸಹ ಅನುಮತಿಸುತ್ತದೆ. `app1` ಮತ್ತು `app2` ಎರಡೂ ಕಂಟೇನರ್‌ನಿಂದ ಹಂಚಿಕೊಳ್ಳದ ಲೈಬ್ರರಿಯನ್ನು ಬಳಸಿದರೆ, ಎರಡೂ ತಮ್ಮ ತಮ್ಮ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳಲ್ಲಿ ಅದನ್ನು ಹಂಚಿಕೆಯಾಗಿ ಘೋಷಿಸಿದರೆ ಅವರು ಅದನ್ನು ಇನ್ನೂ ಹಂಚಿಕೊಳ್ಳಬಹುದು.

ಉದಾಹರಣೆ: `app1` ಮತ್ತು `app2` ಎರಡೂ ಯುಟಿಲಿಟಿ ಲೈಬ್ರರಿ `lodash` ಅನ್ನು ಬಳಸುತ್ತವೆ ಎಂದು ಭಾವಿಸೋಣ.

`app1` ನ ವೆಬ್‌ಪ್ಯಾಕ್ ಕಾನ್ಫಿಗ್ (lodash ಸೇರಿಸುವುದು):

            
// ... within ModuleFederationPlugin for app1
shared: {
  // ... react, react-dom
  'lodash': {
    singleton: true,
    requiredVersion: '^4.17.21',
  },
},

            

              
                Copy
              
            
          

`app2` ನ ವೆಬ್‌ಪ್ಯಾಕ್ ಕಾನ್ಫಿಗ್ (lodash ಸೇರಿಸುವುದು):

            
// ... within ModuleFederationPlugin for app2
shared: {
  // ... react, react-dom
  'lodash': {
    singleton: true,
    requiredVersion: '^4.17.21',
  },
},

            

              
                Copy
              
            
          

ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಕಂಟೇನರ್ `lodash` ಅನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಹಂಚಿಕೊಳ್ಳದಿದ್ದರೂ ಸಹ, `app1` ಮತ್ತು `app2` ತಮ್ಮ ನಡುವೆ `lodash` ನ ಒಂದೇ ಪ್ರತಿಯನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ನಿರ್ವಹಿಸುತ್ತವೆ, ಅವು ಒಂದೇ ಬ್ರೌಸರ್ ಸಂದರ್ಭದಲ್ಲಿ ಲೋಡ್ ಆಗಿದ್ದರೆ.

ಆವೃತ್ತಿ ಹೊಂದಾಣಿಕೆಯಿಲ್ಲದನ್ನು ನಿರ್ವಹಿಸುವುದು

ಅವಲಂಬನೆ ಹಂಚಿಕೆಯಲ್ಲಿ ಅತ್ಯಂತ ಸಾಮಾನ್ಯವಾದ ಸವಾಲುಗಳಲ್ಲಿ ಒಂದು ಆವೃತ್ತಿಯ ಹೊಂದಾಣಿಕೆಯಾಗಿದೆ. `app1` ಗೆ `react` v18.1.0 ಮತ್ತು `app2` ಗೆ `react` v18.2.0 ಅಗತ್ಯವಿದ್ದಾಗ ಏನಾಗುತ್ತದೆ? ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ಈ ಸನ್ನಿವೇಶಗಳನ್ನು ನಿರ್ವಹಿಸಲು ದೃಢವಾದ ತಂತ್ರಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ.

1. ಕಟ್ಟುನಿಟ್ಟಾದ ಆವೃತ್ತಿ ಹೊಂದಾಣಿಕೆ (`requiredVersion` ಗಾಗಿ ಡೀಫಾಲ್ಟ್ ನಡವಳಿಕೆ)

ನೀವು ನಿಖರವಾದ ಆವೃತ್ತಿಯನ್ನು (ಉದಾ., '18.1.0') ಅಥವಾ ಕಟ್ಟುನಿಟ್ಟಾದ ಶ್ರೇಣಿಯನ್ನು (ಉದಾ., '^18.1.0') ನಿರ್ದಿಷ್ಟಪಡಿಸಿದಾಗ, ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ಇದನ್ನು ಜಾರಿಗೊಳಿಸುತ್ತದೆ. ಒಂದು ಅಪ್ಲಿಕೇಶನ್ ಈಗಾಗಲೇ ಅದನ್ನು ಬಳಸುತ್ತಿರುವ ಮತ್ತೊಂದು ಅಪ್ಲಿಕೇಶನ್‌ನ ಅವಶ್ಯಕತೆಯನ್ನು ಪೂರೈಸದ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಹಂಚಿಕೆಯ ಅವಲಂಬನೆಯನ್ನು ಲೋಡ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದರೆ, ಅದು ದೋಷಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು.

2. ಆವೃತ್ತಿ ಶ್ರೇಣಿಗಳು ಮತ್ತು ಫಾಲ್‌ಬ್ಯಾಕ್‌ಗಳು

requiredVersion ಆಯ್ಕೆಯು ಸೆಮ್ಯಾಂಟಿಕ್ ಆವೃತ್ತಿ (SemVer) ಶ್ರೇಣಿಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, '^18.0.0' ಎಂದರೆ 18.0.0 ರಿಂದ 19.0.0 ವರೆಗಿನ (ಆದರೆ 19.0.0 ಅನ್ನು ಒಳಗೊಂಡಿಲ್ಲ) ಯಾವುದೇ ಆವೃತ್ತಿ. ಅನೇಕ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಈ ಶ್ರೇಣಿಯೊಳಗಿನ ಆವೃತ್ತಿಗಳು ಬೇಕಾದರೆ, ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ಸಾಮಾನ್ಯವಾಗಿ ಎಲ್ಲಾ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪೂರೈಸುವ ಅತ್ಯುನ್ನತ ಹೊಂದಾಣಿಕೆಯ ಆವೃತ್ತಿಯನ್ನು ಬಳಸುತ್ತದೆ.

ಇದನ್ನು ಪರಿಗಣಿಸಿ:

• ಕಂಟೇನರ್: shared: { 'react': { requiredVersion: '^18.0.0' } }
• `app1`: shared: { 'react': { requiredVersion: '^18.1.0' } }
• `app2`: shared: { 'react': { requiredVersion: '^18.2.0' } }

ಕಂಟೇನರ್ ಮೊದಲು ಲೋಡ್ ಆಗಿದ್ದರೆ, ಅದು `react` v18.0.0 ಅನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ (ಅಥವಾ ಅದು ನಿಜವಾಗಿ ಬಂಡಲ್ ಮಾಡುವ ಯಾವುದೇ ಆವೃತ್ತಿ). `app1` `^18.1.0` ನೊಂದಿಗೆ `react` ಅನ್ನು ವಿನಂತಿಸಿದಾಗ, ಕಂಟೇನರ್‌ನ ಆವೃತ್ತಿ 18.1.0 ಕ್ಕಿಂತ ಕಡಿಮೆಯಿದ್ದರೆ ಅದು ವಿಫಲವಾಗಬಹುದು. ಆದಾಗ್ಯೂ, `app1` ಮೊದಲು ಲೋಡ್ ಆಗಿ `react` v18.1.0 ಅನ್ನು ಒದಗಿಸಿದರೆ, ಮತ್ತು ನಂತರ `app2` `^18.2.0` ನೊಂದಿಗೆ `react` ಅನ್ನು ವಿನಂತಿಸಿದರೆ, ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ `app2` ನ ಅವಶ್ಯಕತೆಯನ್ನು ಪೂರೈಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. `react` v18.1.0 ಪ್ರತಿ ಈಗಾಗಲೇ ಲೋಡ್ ಆಗಿದ್ದರೆ, ಅದು ದೋಷವನ್ನು ನೀಡಬಹುದು ಏಕೆಂದರೆ v18.1.0 `^18.2.0` ಅನ್ನು ಪೂರೈಸುವುದಿಲ್ಲ.

ಇದನ್ನು ತಗ್ಗಿಸಲು, ಹಂಚಿಕೆಯ ಅವಲಂಬನೆಗಳನ್ನು ಅತ್ಯಂತ ವಿಶಾಲವಾದ ಸ್ವೀಕಾರಾರ್ಹ ಆವೃತ್ತಿ ಶ್ರೇಣಿಯೊಂದಿಗೆ ವ್ಯಾಖ್ಯಾನಿಸುವುದು ಉತ್ತಮ ಅಭ್ಯಾಸವಾಗಿದೆ, ಸಾಮಾನ್ಯವಾಗಿ ಕಂಟೇನರ್ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ. ಉದಾಹರಣೆಗೆ, '^18.0.0' ಅನ್ನು ಬಳಸುವುದು ನಮ್ಯತೆಯನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಒಂದು ನಿರ್ದಿಷ್ಟ ರಿಮೋಟ್ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಹೊಸ ಪ್ಯಾಚ್ ಆವೃತ್ತಿಯ ಮೇಲೆ ಕಠಿಣ ಅವಲಂಬನೆ ಇದ್ದರೆ, ಆ ಆವೃತ್ತಿಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಒದಗಿಸಲು ಅದನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕು.

3. `shareKey` ಮತ್ತು `shareScope` ಬಳಸುವುದು

ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ಒಂದು ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಹಂಚಿಕೊಳ್ಳುವ ಕೀ ಮತ್ತು ಅದು ಇರುವ ವ್ಯಾಪ್ತಿಯನ್ನು ನಿಯಂತ್ರಿಸಲು ಸಹ ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಸುಧಾರಿತ ಸನ್ನಿವೇಶಗಳಿಗೆ ಇದು ಉಪಯುಕ್ತವಾಗಬಹುದು, ಉದಾಹರಣೆಗೆ ಒಂದೇ ಲೈಬ್ರರಿಯ ವಿಭಿನ್ನ ಆವೃತ್ತಿಗಳನ್ನು ವಿಭಿನ್ನ ಕೀಗಳ ಅಡಿಯಲ್ಲಿ ಹಂಚಿಕೊಳ್ಳುವುದು.

4. `strictVersion` ಆಯ್ಕೆ

strictVersion ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದಾಗ (ಇದು requiredVersion ಗಾಗಿ ಡೀಫಾಲ್ಟ್ ಆಗಿದೆ), ಅವಲಂಬನೆಯನ್ನು ಪೂರೈಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ದೋಷವನ್ನು ನೀಡುತ್ತದೆ. strictVersion: false ಎಂದು ಹೊಂದಿಸುವುದರಿಂದ ಹೆಚ್ಚು ಮೃದುವಾದ ಆವೃತ್ತಿ ನಿರ್ವಹಣೆಗೆ ಅವಕಾಶ ನೀಡಬಹುದು, ಅಲ್ಲಿ ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ಹೊಸದು ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೆ ಹಳೆಯ ಆವೃತ್ತಿಯನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸಬಹುದು, ಆದರೆ ಇದು ರನ್‌ಟೈಮ್ ದೋಷಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು.

ಹಂಚಿಕೆಯ ವ್ಯಾಪ್ತಿಯನ್ನು ಬಳಸಲು ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು

ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್‌ನ ಹಂಚಿಕೆಯ ವ್ಯಾಪ್ತಿಯನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಬಳಸಿಕೊಳ್ಳಲು ಮತ್ತು ಸಾಮಾನ್ಯ ಅಪಾಯಗಳನ್ನು ತಪ್ಪಿಸಲು, ಈ ಉತ್ತಮ ಅಭ್ಯಾಸಗಳನ್ನು ಪರಿಗಣಿಸಿ:

1. ಹಂಚಿಕೆಯ ಅವಲಂಬನೆಗಳನ್ನು ಕೇಂದ್ರೀಕರಿಸಿ: ಸಾಮಾನ್ಯ, ಸ್ಥಿರ ಅವಲಂಬನೆಗಳಾದ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳು (ರಿಯಾಕ್ಟ್, ವ್ಯೂ, ಆಂಗ್ಯುಲರ್), UI ಕಾಂಪೊನೆಂಟ್ ಲೈಬ್ರರಿಗಳು, ಮತ್ತು ಸ್ಟೇಟ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಲೈಬ್ರರಿಗಳಿಗೆ ಸತ್ಯದ ಮೂಲವಾಗಿರಲು ಪ್ರಾಥಮಿಕ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು (ಸಾಮಾನ್ಯವಾಗಿ ಕಂಟೇನರ್ ಅಥವಾ ಮೀಸಲಾದ ಹಂಚಿಕೆಯ ಲೈಬ್ರರಿ ಅಪ್ಲಿಕೇಶನ್) ಗೊತ್ತುಪಡಿಸಿ.
2. ವಿಶಾಲ ಆವೃತ್ತಿಯ ಶ್ರೇಣಿಗಳನ್ನು ವಿವರಿಸಿ: ಪ್ರಾಥಮಿಕ ಹಂಚಿಕೆ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಹಂಚಿಕೆಯ ಅವಲಂಬನೆಗಳಿಗಾಗಿ SemVer ಶ್ರೇಣಿಗಳನ್ನು (ಉದಾ., '^18.0.0') ಬಳಸಿ. ಇದು ಇತರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಸಂಪೂರ್ಣ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯಾದ್ಯಂತ ಕಟ್ಟುನಿಟ್ಟಾದ ನವೀಕರಣಗಳನ್ನು ಒತ್ತಾಯಿಸದೆ ಹೊಂದಾಣಿಕೆಯ ಆವೃತ್ತಿಗಳನ್ನು ಬಳಸಲು ಅನುಮತಿಸುತ್ತದೆ.
3. ಹಂಚಿಕೆಯ ಅವಲಂಬನೆಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ದಾಖಲಿಸಿ: ಯಾವ ಅವಲಂಬನೆಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಲಾಗಿದೆ, ಅವುಗಳ ಆವೃತ್ತಿಗಳು, ಮತ್ತು ಅವುಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಯಾವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಜವಾಬ್ದಾರವಾಗಿವೆ ಎಂಬುದರ ಬಗ್ಗೆ ಸ್ಪಷ್ಟವಾದ ದಸ್ತಾವೇಜನ್ನು ನಿರ್ವಹಿಸಿ. ಇದು ತಂಡಗಳಿಗೆ ಅವಲಂಬನೆಯ ಗ್ರಾಫ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
4. ಬಂಡಲ್ ಗಾತ್ರಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ: ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಬಂಡಲ್ ಗಾತ್ರಗಳನ್ನು ನಿಯಮಿತವಾಗಿ ವಿಶ್ಲೇಷಿಸಿ. ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್‌ನ ಹಂಚಿಕೆಯ ವ್ಯಾಪ್ತಿಯು ಸಾಮಾನ್ಯ ಅವಲಂಬನೆಗಳನ್ನು ಬಾಹ್ಯೀಕರಿಸುವುದರಿಂದ ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಲೋಡ್ ಮಾಡಲಾದ ಚಂಕ್‌ಗಳ ಗಾತ್ರದಲ್ಲಿ ಕಡಿತಕ್ಕೆ ಕಾರಣವಾಗಬೇಕು.
5. ನಿರ್ಣಾಯಕವಲ್ಲದ ಅವಲಂಬನೆಗಳನ್ನು ನಿರ್ವಹಿಸಿ: ಆಗಾಗ್ಗೆ ನವೀಕರಿಸಲಾಗುವ ಅಥವಾ ಅಸ್ಥಿರ API ಗಳನ್ನು ಹೊಂದಿರುವ ಅವಲಂಬನೆಗಳ ಬಗ್ಗೆ ಜಾಗರೂಕರಾಗಿರಿ. ಅಂತಹ ಅವಲಂಬನೆಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಹೆಚ್ಚು ಎಚ್ಚರಿಕೆಯ ಆವೃತ್ತಿ ನಿರ್ವಹಣೆ ಮತ್ತು ಪರೀಕ್ಷೆಯ ಅಗತ್ಯವಿರಬಹುದು.
6. `eager: true` ಅನ್ನು ವಿವೇಚನೆಯಿಂದ ಬಳಸಿ: `eager: true` ಅವಲಂಬನೆಯನ್ನು ಬೇಗನೆ ಲೋಡ್ ಮಾಡುವುದನ್ನು ಖಚಿತಪಡಿಸಿದರೂ, ಅತಿಯಾದ ಬಳಕೆಯು ದೊಡ್ಡ ಆರಂಭಿಕ ಲೋಡ್‌ಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು. ಅಪ್ಲಿಕೇಶನ್‌ನ ಪ್ರಾರಂಭಕ್ಕೆ ಅಗತ್ಯವಾದ ನಿರ್ಣಾಯಕ ಲೈಬ್ರರಿಗಳಿಗಾಗಿ ಇದನ್ನು ಬಳಸಿ.
7. ಪರೀಕ್ಷೆ ನಿರ್ಣಾಯಕವಾಗಿದೆ: ನಿಮ್ಮ ಮೈಕ್ರೋಫ್ರಂಟೆಂಡ್‌ಗಳ ಏಕೀಕರಣವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪರೀಕ್ಷಿಸಿ. ಹಂಚಿಕೆಯ ಅವಲಂಬನೆಗಳು ಸರಿಯಾಗಿ ಲೋಡ್ ಆಗಿವೆಯೇ ಮತ್ತು ಆವೃತ್ತಿಯ ಸಂಘರ್ಷಗಳನ್ನು ಸರಿಯಾಗಿ ನಿರ್ವಹಿಸಲಾಗಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆ, ಏಕೀಕರಣ ಮತ್ತು ಎಂಡ್-ಟು-ಎಂಡ್ ಪರೀಕ್ಷೆಗಳನ್ನು ಒಳಗೊಂಡಂತೆ, ಅತ್ಯಗತ್ಯ.
8. ಸರಳತೆಗಾಗಿ ಮೊನೊರೆಪೋಗಳನ್ನು ಪರಿಗಣಿಸಿ: ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್‌ನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸುವ ತಂಡಗಳಿಗೆ, ಮೊನೊರೆಪೋದಲ್ಲಿ (ಲೆರ್ನಾ ಅಥವಾ ಯಾರ್ನ್ ವರ್ಕ್‌ಸ್ಪೇಸ್‌ಗಳಂತಹ ಪರಿಕರಗಳನ್ನು ಬಳಸಿ) ಹಂಚಿಕೆಯ ಅವಲಂಬನೆಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು ಸೆಟಪ್ ಅನ್ನು ಸರಳಗೊಳಿಸಬಹುದು ಮತ್ತು ಸ್ಥಿರತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬಹುದು. `packageDir` ಆಯ್ಕೆಯು ಇಲ್ಲಿ ವಿಶೇಷವಾಗಿ ಉಪಯುಕ್ತವಾಗಿದೆ.
9. `shareKey` ಮತ್ತು `shareScope` ನೊಂದಿಗೆ ಎಡ್ಜ್ ಕೇಸ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸಿ: ನೀವು ಸಂಕೀರ್ಣ ಆವೃತ್ತಿಯ ಸನ್ನಿವೇಶಗಳನ್ನು ಎದುರಿಸಿದರೆ ಅಥವಾ ಒಂದೇ ಲೈಬ್ರರಿಯ ವಿಭಿನ್ನ ಆವೃತ್ತಿಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸಬೇಕಾದರೆ, ಹೆಚ್ಚು ಸೂಕ್ಷ್ಮ ನಿಯಂತ್ರಣಕ್ಕಾಗಿ `shareKey` ಮತ್ತು `shareScope` ಆಯ್ಕೆಗಳನ್ನು ಅನ್ವೇಷಿಸಿ.
10. ಭದ್ರತಾ ಪರಿಗಣನೆಗಳು: ಹಂಚಿಕೆಯ ಅವಲಂಬನೆಗಳನ್ನು ವಿಶ್ವಾಸಾರ್ಹ ಮೂಲಗಳಿಂದ ಪಡೆಯಲಾಗಿದೆಯೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ನಿಮ್ಮ ಬಿಲ್ಡ್ ಪೈಪ್‌ಲೈನ್ ಮತ್ತು ನಿಯೋಜನೆ ಪ್ರಕ್ರಿಯೆಗಾಗಿ ಭದ್ರತಾ ಉತ್ತಮ ಅಭ್ಯಾಸಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿ.

ಜಾಗತಿಕ ಪರಿಣಾಮ ಮತ್ತು ಪರಿಗಣನೆಗಳು

ಜಾಗತಿಕ ಅಭಿವೃದ್ಧಿ ತಂಡಗಳಿಗೆ, ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ಮತ್ತು ಅದರ ಹಂಚಿಕೆಯ ವ್ಯಾಪ್ತಿಯು ಗಮನಾರ್ಹ ಪ್ರಯೋಜನಗಳನ್ನು ನೀಡುತ್ತದೆ:

• ಪ್ರದೇಶಗಳಾದ್ಯಂತ ಸ್ಥಿರತೆ: ಎಲ್ಲಾ ಬಳಕೆದಾರರು, ಅವರ ಭೌಗೋಳಿಕ ಸ್ಥಳವನ್ನು ಲೆಕ್ಕಿಸದೆ, ಒಂದೇ ಮೂಲಭೂತ ಅವಲಂಬನೆಗಳೊಂದಿಗೆ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಅನುಭವಿಸುತ್ತಾರೆ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ, ಪ್ರಾದೇಶಿಕ ಅಸಂಗತತೆಗಳನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
• ವೇಗದ ಪುನರಾವರ್ತನೆ ಚಕ್ರಗಳು: ವಿಭಿನ್ನ ಸಮಯ ವಲಯಗಳಲ್ಲಿನ ತಂಡಗಳು ಸಾಮಾನ್ಯ ಲೈಬ್ರರಿಗಳನ್ನು ನಕಲು ಮಾಡುವ ಬಗ್ಗೆ ಅಥವಾ ಅವಲಂಬನೆ ಆವೃತ್ತಿಗಳ ಬಗ್ಗೆ ಪರಸ್ಪರರ ಕೆಲಸದಲ್ಲಿ ಅಡ್ಡಿಪಡಿಸುವ ಬಗ್ಗೆ ನಿರಂತರವಾಗಿ ಚಿಂತಿಸದೆ ಸ್ವತಂತ್ರ ವೈಶಿಷ್ಟ್ಯಗಳು ಅಥವಾ ಮೈಕ್ರೋಫ್ರಂಟೆಂಡ್‌ಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡಬಹುದು.
• ವೈವಿಧ್ಯಮಯ ನೆಟ್‌ವರ್ಕ್‌ಗಳಿಗಾಗಿ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲಾಗಿದೆ: ಹಂಚಿಕೆಯ ಅವಲಂಬನೆಗಳ ಮೂಲಕ ಒಟ್ಟಾರೆ ಡೌನ್‌ಲೋಡ್ ಗಾತ್ರವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು ನಿಧಾನಗತಿಯ ಅಥವಾ ಮೀಟರ್ ಮಾಡಿದ ಇಂಟರ್ನೆಟ್ ಸಂಪರ್ಕಗಳಲ್ಲಿರುವ ಬಳಕೆದಾರರಿಗೆ ವಿಶೇಷವಾಗಿ ಪ್ರಯೋಜನಕಾರಿಯಾಗಿದೆ, ಇದು ಪ್ರಪಂಚದ ಅನೇಕ ಭಾಗಗಳಲ್ಲಿ ಪ್ರಚಲಿತವಾಗಿದೆ.
• ಸರಳೀಕೃತ ಆನ್‌ಬೋರ್ಡಿಂಗ್: ದೊಡ್ಡ ಯೋಜನೆಗೆ ಸೇರುವ ಹೊಸ ಡೆವಲಪರ್‌ಗಳು ಸಾಮಾನ್ಯ ಲೈಬ್ರರಿಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಿದಾಗ ಮತ್ತು ಹಂಚಿಕೊಂಡಾಗ ಅಪ್ಲಿಕೇಶನ್‌ನ ಆರ್ಕಿಟೆಕ್ಚರ್ ಮತ್ತು ಅವಲಂಬನೆ ನಿರ್ವಹಣೆಯನ್ನು ಹೆಚ್ಚು ಸುಲಭವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು.

ಆದಾಗ್ಯೂ, ಜಾಗತಿಕ ತಂಡಗಳು ಇವುಗಳ ಬಗ್ಗೆಯೂ ಗಮನಹರಿಸಬೇಕು:

• CDN ತಂತ್ರಗಳು: ಹಂಚಿಕೆಯ ಅವಲಂಬನೆಗಳನ್ನು CDN ನಲ್ಲಿ ಹೋಸ್ಟ್ ಮಾಡಿದ್ದರೆ, CDN ಎಲ್ಲಾ ಗುರಿ ಪ್ರದೇಶಗಳಿಗೆ ಉತ್ತಮ ಜಾಗತಿಕ ವ್ಯಾಪ್ತಿ ಮತ್ತು ಕಡಿಮೆ ವಿಳಂಬವನ್ನು ಹೊಂದಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
• ಆಫ್‌ಲೈನ್ ಬೆಂಬಲ: ಆಫ್‌ಲೈನ್ ಸಾಮರ್ಥ್ಯಗಳ ಅಗತ್ಯವಿರುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ, ಹಂಚಿಕೆಯ ಅವಲಂಬನೆಗಳು ಮತ್ತು ಅವುಗಳ ಕ್ಯಾಶಿಂಗ್ ಅನ್ನು ನಿರ್ವಹಿಸುವುದು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗುತ್ತದೆ.
• ನಿಯಂತ್ರಕ ಅನುಸರಣೆ: ಲೈಬ್ರರಿಗಳ ಹಂಚಿಕೆಯು ವಿಭಿನ್ನ ನ್ಯಾಯವ್ಯಾಪ್ತಿಗಳಲ್ಲಿ ಯಾವುದೇ ಸಂಬಂಧಿತ ಸಾಫ್ಟ್‌ವೇರ್ ಪರವಾನಗಿ ಅಥವಾ ಡೇಟಾ ಗೌಪ್ಯತೆ ನಿಯಮಗಳಿಗೆ ಅನುಗುಣವಾಗಿದೆಯೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.

ಸಾಮಾನ್ಯ ಅಪಾಯಗಳು ಮತ್ತು ಅವುಗಳನ್ನು ತಪ್ಪಿಸುವುದು ಹೇಗೆ

1. ತಪ್ಪಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ `singleton`

ಸಮಸ್ಯೆ: ಒಂದೇ ಒಂದು ಪ್ರತಿ ಮಾತ್ರ ಇರಬೇಕಾದ ಲೈಬ್ರರಿಗಳಿಗಾಗಿ singleton: true ಎಂದು ಹೊಂದಿಸಲು ಮರೆಯುವುದು.

ಪರಿಹಾರ: ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಾದ್ಯಂತ ಅನನ್ಯವಾಗಿ ಹಂಚಿಕೊಳ್ಳಲು ನೀವು ಉದ್ದೇಶಿಸಿರುವ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳು, ಲೈಬ್ರರಿಗಳು, ಮತ್ತು ಯುಟಿಲಿಟಿಗಳಿಗಾಗಿ ಯಾವಾಗಲೂ singleton: true ಎಂದು ಹೊಂದಿಸಿ.

2. ಅಸಂಗತ ಆವೃತ್ತಿ ಅವಶ್ಯಕತೆಗಳು

ಸಮಸ್ಯೆ: ವಿಭಿನ್ನ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಒಂದೇ ಹಂಚಿಕೆಯ ಅವಲಂಬನೆಗಾಗಿ ವಿಭಿನ್ನ, ಹೊಂದಾಣಿಕೆಯಾಗದ ಆವೃತ್ತಿ ಶ್ರೇಣಿಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವುದು.

ಪರಿಹಾರ: ಆವೃತ್ತಿ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪ್ರಮಾಣೀಕರಿಸಿ, ವಿಶೇಷವಾಗಿ ಕಂಟೇನರ್ ಆ್ಯಪ್‌ನಲ್ಲಿ. ವಿಶಾಲವಾದ SemVer ಶ್ರೇಣಿಗಳನ್ನು ಬಳಸಿ ಮತ್ತು ಯಾವುದೇ ವಿನಾಯಿತಿಗಳನ್ನು ದಾಖಲಿಸಿ.

3. ಅತ್ಯಗತ್ಯವಲ್ಲದ ಲೈಬ್ರರಿಗಳನ್ನು ಅತಿಯಾಗಿ ಹಂಚಿಕೊಳ್ಳುವುದು

ಸಮಸ್ಯೆ: ಪ್ರತಿಯೊಂದು ಸಣ್ಣ ಯುಟಿಲಿಟಿ ಲೈಬ್ರರಿಯನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸುವುದು, ಇದು ಸಂಕೀರ್ಣ ಕಾನ್ಫಿಗರೇಶನ್ ಮತ್ತು ಸಂಭಾವ್ಯ ಸಂಘರ್ಷಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ.

ಪರಿಹಾರ: ದೊಡ್ಡ, ಸಾಮಾನ್ಯ, ಮತ್ತು ಸ್ಥಿರ ಅವಲಂಬನೆಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುವುದರ ಮೇಲೆ ಗಮನಹರಿಸಿ. ಸಣ್ಣ, ಅಪರೂಪವಾಗಿ ಬಳಸಲಾಗುವ ಯುಟಿಲಿಟಿಗಳನ್ನು ಸಂಕೀರ್ಣತೆಯನ್ನು ತಪ್ಪಿಸಲು ಸ್ಥಳೀಯವಾಗಿ ಬಂಡಲ್ ಮಾಡುವುದು ಉತ್ತಮ.

4. `remoteEntry.js` ಫೈಲ್ ಅನ್ನು ಸರಿಯಾಗಿ ನಿರ್ವಹಿಸದಿರುವುದು

ಸಮಸ್ಯೆ: `remoteEntry.js` ಫೈಲ್ ಲಭ್ಯವಿಲ್ಲದಿರುವುದು ಅಥವಾ ಬಳಸುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಸರಿಯಾಗಿ ಸರ್ವ್ ಆಗದಿರುವುದು.

ಪರಿಹಾರ: ರಿಮೋಟ್ ಎಂಟ್ರಿಗಳಿಗಾಗಿ ನಿಮ್ಮ ಹೋಸ್ಟಿಂಗ್ ತಂತ್ರವು ದೃಢವಾಗಿದೆಯೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ ಮತ್ತು `remotes` ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ URL ಗಳು ನಿಖರ ಮತ್ತು ಲಭ್ಯವಿವೆಯೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.

5. `eager: true` ಪರಿಣಾಮಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸುವುದು

ಸಮಸ್ಯೆ: ಹಲವಾರು ಅವಲಂಬನೆಗಳ ಮೇಲೆ eager: true ಎಂದು ಹೊಂದಿಸುವುದು, ಇದು ನಿಧಾನವಾದ ಆರಂಭಿಕ ಲೋಡ್ ಸಮಯಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ.

ಪರಿಹಾರ: ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಆರಂಭಿಕ ರೆಂಡರಿಂಗ್ ಅಥವಾ ಪ್ರಮುಖ ಕಾರ್ಯಚಟುವಟಿಕೆಗೆ ಸಂಪೂರ್ಣವಾಗಿ ನಿರ್ಣಾಯಕವಾಗಿರುವ ಅವಲಂಬನೆಗಳಿಗೆ ಮಾತ್ರ `eager: true` ಅನ್ನು ಬಳಸಿ.

ತೀರ್ಮಾನ

ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್‌ನ ಹಂಚಿಕೆಯ ವ್ಯಾಪ್ತಿಯು ಆಧುನಿಕ, ವಿಸ್ತರಿಸಬಲ್ಲ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು, ವಿಶೇಷವಾಗಿ ಮೈಕ್ರೋಫ್ರಂಟೆಂಡ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿ ಒಂದು ಪ್ರಬಲ ಸಾಧನವಾಗಿದೆ. ದಕ್ಷ ಅವಲಂಬನೆ ಹಂಚಿಕೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವ ಮೂಲಕ, ಇದು ಕೋಡ್ ನಕಲು, ಬ್ಲೋಟ್, ಮತ್ತು ಅಸಂಗತತೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ, ಇದು ಸುಧಾರಿತ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ನಿರ್ವಹಣೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ಈ ಪ್ರಯೋಜನಗಳನ್ನು ಅನ್‌ಲಾಕ್ ಮಾಡಲು shared ಆಯ್ಕೆಯನ್ನು, ವಿಶೇಷವಾಗಿ singleton ಮತ್ತು requiredVersion ಗುಣಲಕ್ಷಣಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಮತ್ತು ಸರಿಯಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡುವುದು ಮುಖ್ಯವಾಗಿದೆ.

ಜಾಗತಿಕ ಅಭಿವೃದ್ಧಿ ತಂಡಗಳು ಹೆಚ್ಚೆಚ್ಚು ಮೈಕ್ರೋಫ್ರಂಟೆಂಡ್ ತಂತ್ರಗಳನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುತ್ತಿದ್ದಂತೆ, ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್‌ನ ಹಂಚಿಕೆಯ ವ್ಯಾಪ್ತಿಯಲ್ಲಿ ಪ್ರಾವೀಣ್ಯತೆ ಪಡೆಯುವುದು ಅತ್ಯಗತ್ಯವಾಗುತ್ತದೆ. ಉತ್ತಮ ಅಭ್ಯಾಸಗಳಿಗೆ ಬದ್ಧರಾಗುವ ಮೂಲಕ, ಆವೃತ್ತಿ ನಿರ್ವಹಣೆಯನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ನಿರ್ವಹಿಸುವ ಮೂಲಕ, ಮತ್ತು ಸಂಪೂರ್ಣ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸುವ ಮೂಲಕ, ನೀವು ದೃಢವಾದ, ಉತ್ತಮ ಕಾರ್ಯಕ್ಷಮತೆಯ, ಮತ್ತು ನಿರ್ವಹಿಸಬಲ್ಲ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಈ ತಂತ್ರಜ್ಞಾನವನ್ನು ಬಳಸಿಕೊಳ್ಳಬಹುದು, ಅದು ವೈವಿಧ್ಯಮಯ ಅಂತರರಾಷ್ಟ್ರೀಯ ಬಳಕೆದಾರರಿಗೆ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಸೇವೆ ಸಲ್ಲಿಸುತ್ತದೆ.

ಹಂಚಿಕೆಯ ವ್ಯಾಪ್ತಿಯ ಶಕ್ತಿಯನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳಿ, ಮತ್ತು ನಿಮ್ಮ ಸಂಸ್ಥೆಯಾದ್ಯಂತ ಹೆಚ್ಚು ದಕ್ಷ ಮತ್ತು ಸಹಯೋಗದ ವೆಬ್ ಅಭಿವೃದ್ಧಿಗೆ ದಾರಿ ಮಾಡಿಕೊಡಿ.